Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

352
Visualizações
Cómo corregir "Error interno: variable no encontrada en la lista de objetivos del subplan"

Tengo un proyecto Django heredado (django-1.1.29) y algunas pruebas en pytest (pytest-4.3.0), todas ejecutándose dentro de Docker. La base de datos es PostgreSQL 10 y es un servicio docker-compose del que depende la aplicación. La versión de Python es 2.7.18.

Últimamente las pruebas empezaron a fallar con un extraño error:

InternalError: variable not found in subplan target list .

El error ocurre solo cuando cuento la cantidad de objetos de un determinado modelo, por ejemplo, Problem.objects.count() . La instrucción se convierte en la siguiente consulta

(0.000) SELECT COUNT(*) AS "__count" FROM "problems_problem"; args=() por Django.

El registro completo está aquí:

 self = <integration_tests.project_name.subjects.test_views.test_theme_problem_view_set.TestThemeProblemViewSet object at 0x7f01faccbe50> jclient = <project_name.common.test_utils.json_client.JSONClient object at 0x7f01fadb8ed0> def test_all_is_ok(self, jclient, subject_model, content_manager): url, data = self._main_prepare(jclient, subject_model, content_manager) response = jclient.post_json(url, data[0]) assert response.status_code == 201 > assert Problem.objects.count() == 1 integration_tests/project_name/subjects/test_views/test_theme_problem_view_set.py:86: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ /usr/local/lib/python2.7/dist-packages/django/db/models/manager.py:85: in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) /usr/local/lib/python2.7/dist-packages/django/db/models/query.py:364: in count return self.query.get_count(using=self.db) /usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py:499: in get_count number = obj.get_aggregation(using, ['__count'])['__count'] /usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py:480: in get_aggregation result = compiler.execute_sql(SINGLE) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <django.db.models.sql.compiler.SQLCompiler object at 0x7f01faee3a50> result_type = 'single', chunked_fetch = False def execute_sql(self, result_type=MULTI, chunked_fetch=False): """ Run the query against the database and returns the result(s). The return value is a single data item if result_type is SINGLE, or an iterator over the results if the result_type is MULTI. result_type is either MULTI (use fetchmany() to retrieve all rows), SINGLE (only retrieve a single row), or None. In this last case, the cursor is returned if any query is executed, since it's used by subclasses such as InsertQuery). It's possible, however, that no query is needed, as the filters describe an empty set. In that case, None is returned, to avoid any unnecessary database interaction. """ if not result_type: result_type = NO_RESULTS try: sql, params = self.as_sql() if not sql: raise EmptyResultSet except EmptyResultSet: if result_type == MULTI: return iter([]) else: return if chunked_fetch: cursor = self.connection.chunked_cursor() else: cursor = self.connection.cursor() try: cursor.execute(sql, params) except Exception as original_exception: try: # Might fail for server-side cursors (eg connection closed) cursor.close() except Exception: # Ignore clean up errors and raise the original error instead. # Python 2 doesn't chain exceptions. Remove this error # silencing when dropping Python 2 compatibility. pass > raise original_exception E InternalError: variable not found in subplan target list /usr/local/lib/python2.7/dist-packages/django/db/models/sql/compiler.py:899: InternalError

Realmente agradecería si alguien pudiera ayudarme a solucionar este problema o al menos dar algunos consejos sobre dónde encontrar las razones.

Esto es lo que he intentado hacer hasta ahora, pero ninguno de estos ayudó:

  • Use diferentes versiones de PostgreSQL (10, 11, 12, 13)
  • Deshabilitar el cursor del lado del servidor
over 4 years ago · Santiago Trujillo
1 Respostas
Responde à pergunta

0

Parece que Postgres ha enviado algo roto en todas sus versiones menores:

https://www.postgresql.org/message-id/2121219.1644607692%40sss.pgh.pa.us

Por ejemplo, la imagen dockerhub postgres:12 ahora es la misma que la imagen dockerhub postgres:12.10 en lugar de 12.9. Si especifica explícitamente postgres: 12.9 (o la versión menor anterior para cualquiera de las otras versiones), creo que comenzará a funcionar.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda